Enforce ruby and bundler versions by sethboyles · Pull Request #4545 · cloudfoundry/cloud_controller_ng

sethboyles · 2025-09-03T22:24:51Z

The Problem

There's some tricky behaviour with the CAPI pre-packaging/packaging process and how it uses Bundler that I think can be particularly confusing, especially to those new to contributing to CCNG that'd I'd like to document here and hopefully mitigate with this PR.

Cloud Controller must always use the default Bundler version with its Ruby version, or CAPI releases will not work on air-gapped environments.

This happens if a the BUNDLED WITH version in the Gemfile.lock is bumped beyond the default, meaning that when it comes time to run bundle in the packaging step, bundler will notice that it does not have the correct version, attempt to download the right version, and fail.

I think these issues can be mitigated by adding the Bundler and Ruby versions to our Gemfile.

Adding bundler to our Gemfile:

If you try to create a dev release with a different version (say you accidentally chruby'd 3.3 so now Bundler is 2.5.X), you get an error during prepackaging:

+ bundle package --all-platforms --no-install
Could not find compatible versions

Because the current Bundler version (2.5.18) does not satisfy bundler ~> 2.4.10
  and Gemfile depends on bundler ~> 2.4.10,
  version solving has failed.

Your bundle requires a different version of Bundler than the one you're running.
Install the necessary version with `gem install bundler:2.4.22` and rerun
bundler using `bundle _2.4.22_ package --all-platforms --no-install`
+ exit_code=6
+ set -e
+ '[' 6 == 0 ']'
+ sleep 1
+ '[' 6 '!=' 0 ']'
+ echo 'ERROR: Failed to run '\''bundle package'\'' after 3 attempts'
+ exit 6
':
              exit status 6

It also won't be possible to bump Gemfile.lock to a new BUNDLED WITH version during a bundle update.

Adding bundler to our Gemfile may allow us to use newer versions of Bundler than what's the Ruby version's default because now the Bundler gem will be vendored like the others and the compilation VM won't need to download it. But I'd have to test on an air-gapped env just to be sure.

That said, I did find this solution relatively inconsistent--there were times where I thought creating a new release would error out because of the Bundler version I had selected, and it was somehow able to succeed.

Adding Ruby version to our Gemfile

Because of the prepackaging step, creating a CAPI bosh release (in this context, usually for testing) is reliant on having the correct Ruby version selected. This might manifest in errors during runtime or compilation, but I've seen this fail most frequently because the wrong Bundler version would be inadvertently selected, and gems would be vendored/packaged with Bundler 2.5, which would hit this bug with Bundler 2.5.

That makes this a little redundant with adding the Bundler version to the Gemfile, but adding the Ruby version to the Gemfile will instead will fail quickly during prepackaging with a clear message:

Your Ruby version is 3.4.2, but your Gemfile specified 3.2.6
+ exit_code=18
+ set -e
+ '[' 18 == 0 ']'
+ sleep 1
+ for i in '{1..3}'
+ bundle config --local specific_platform true
+ bundle config --local path ./vendor/cache
+ bundle config set cache_all true
+ set +e
+ bundle package --all-platforms --no-install

It will also raise an error if someone tries to run CCNG tests (or bundle install, etc) with the wrong Ruby version.

I have reviewed the contributing guide
I have viewed, signed, and submitted the Contributor License Agreement
I have made this pull request to the main branch
I have run all the unit tests using bundle exec rake
I have run CF Acceptance Tests

Gemfile

johha · 2025-09-11T14:47:28Z

I've looked around a bit and could not find any big ruby project which specifies the bundler version in the Gemfile but also don't see any harm in it. For air-gapped envs this could be beneficial to detect version mismatches earlier. From my point this can be merged.

philippthun · 2025-12-02T11:48:53Z

FYI: I've created an action [1] that sets the BUNDLED WITH version to the default bundler version that comes with whatever Ruby version we are using. We've recently updated to Ruby 3.2.9 - this action now updated the Gemfile.lock to the corresponding bundler version [2].

[1] https://github.com/cloudfoundry/cloud_controller_ng/actions/workflows/bump_bundler_version.yml
[2] https://github.com/cloudfoundry/cloud_controller_ng/pull/4692/files

Co-authored-by: Johannes Haass <johannes.haass@sap.com>

This reverts commit 728f705.

sethboyles · 2025-12-12T21:06:21Z

That seems like a good plan until we ever decide to desync bundler and the Ruby version (which we might want to do to upgrade to 3.3). I updated this PR to account for the bump to Ruby 3.2.9. Should I remove the inclusion of bundler in the Gemfile?

sethboyles · 2026-02-02T19:22:09Z

+ set -e -x
+ source /var/vcap/packages/ruby-3.2/bosh/compile.env
++ source /var/vcap/packages/ruby-3.2/bosh/runtime.env
+++ export PATH=/var/vcap/packages/ruby-3.2/bin:/var/vcap/bosh/bin:/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
+++ PATH=/var/vcap/packages/ruby-3.2/bin:/var/vcap/bosh/bin:/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
+++ export GEMRC=/var/vcap/packages/ruby-3.2/bosh/gemrc
+++ GEMRC=/var/vcap/packages/ruby-3.2/bosh/gemrc
++ command -v clang
+++ command -v clang
++ export CC=/bin/clang
++ CC=/bin/clang
++ command -v clang++
+++ command -v clang++
++ export CXX=/bin/clang++
++ CXX=/bin/clang++
+ cp -a cloud_controller_ng packaging /var/vcap/packages/cloud_controller_ng
+ cd /var/vcap/packages/cloud_controller_ng/cloud_controller_ng
+ mariadb_dir=/var/vcap/packages/mariadb_connector_c
+ libpq_dir=/var/vcap/packages/libpq
+ export PATH=/var/vcap/packages/libpq/bin:/var/vcap/packages/ruby-3.2/bin:/var/vcap/bosh/bin:/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
+ PATH=/var/vcap/packages/libpq/bin:/var/vcap/packages/ruby-3.2/bin:/var/vcap/bosh/bin:/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
+ bundle config build.pg --with-pg-lib=/var/vcap/packages/libpq/lib --with-pg-include=/var/vcap/packages/libpq/include
+ bundle config build.mysql2 --with-mysql-config=/var/vcap/packages/mariadb_connector_c/bin/mariadb_config-wrapper.sh
+ bosh_bundle_local --deployment
+ bundle config set --local no_prune true
+ bundle config set --local without 'development test'
+ bundle config set --local path /var/vcap/packages/cloud_controller_ng/gem_home
+ bundle install --local --binstubs /var/vcap/packages/cloud_controller_ng/bin --deployment
[DEPRECATED] The `--deployment` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local deployment 'true'`, and stop using this flag
Don't run Bundler as root. Installing your bundle as root will break this
application for all non-root users on this machine.
Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/ due to underlying error <Net::OpenTimeout: Failed to open TCP connection to rubygems.org:443 (execution expired) (https://rubygems.org/specs.4.8.gz)>
Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/ due to underlying error <Net::OpenTimeout: Failed to open TCP connection to rubygems.org:443 (execution expired) (https://rubygems.org/specs.4.8.gz)>
Retrying fetcher due to error (4/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/ due to underlying error <Net::OpenTimeout: Failed to open TCP connection to rubygems.org:443 (execution expired) (https://rubygems.org/specs.4.8.gz)>
There was an error installing the locked bundler version (2.5.1), rerun with the `--verbose` flag for more details. Going on using bundler 2.4.22.

These are logs from an air-gapped compilation VM when the bundler lock a non-default Bundler version.

This causes the compilation step to take a long time, but it does eventually succeed. I seem to recall hitting errors when desyncing the bundler version, but I cannot reproduce them now. There was an old issue that also had to do with an issue in the ruby bosh package itself, but I don't think it was the mismatched bundler version alone.

Still, it doesn't seem great that the compilation phase wastes time trying to connect to RubyGems, and I'm not sure what kind of issues might arise from using the wrong bundler version.

Vendoring bundler is not actually possible, even if specified in the Gemfile. Bundler seems to make an exception for itself and it will not appear in vendor/cache. So this solution will not work (and would be more complicated anyway, as the bundled gem wouldn't immediately become available to the system gem space)--we would instead to do something like this:

# in prepackaging
gem fetch bundler -v 2.5.1
mv somewhere/in/capi/release

(alternatively, just commit the gemfile directly to our repo)

# in packaging
gem install --local vendor/cache/bundler-2.5.1.gem

Given this isn't an outright failure, I'm not sure it's worth the trouble. On the other hand, I still wouldn't be comfortable desyncing the bundler version since offline envs would end up having subtle differences, and I'm not sure there is another way to prevent BUNDLED WITH from getting out of sync.

sethboyles force-pushed the enforce_ruby_and_bundler_versions branch 3 times, most recently from 46b87bc to a50bc0d Compare September 5, 2025 20:19

johha reviewed Sep 11, 2025

View reviewed changes

Gemfile Outdated Show resolved Hide resolved

sethboyles force-pushed the enforce_ruby_and_bundler_versions branch from a50bc0d to 2014891 Compare September 16, 2025 17:57

philippthun previously approved these changes Sep 17, 2025

View reviewed changes

sethboyles dismissed philippthun’s stale review via 728f705 October 6, 2025 20:24

johha previously approved these changes Oct 8, 2025

View reviewed changes

Samze previously approved these changes Nov 4, 2025

View reviewed changes

sethboyles and others added 4 commits December 12, 2025 13:48

Enforce ruby and bundler versions

6dcd281

Apply suggestion from @johha

6acabaf

Co-authored-by: Johannes Haass <johannes.haass@sap.com>

Revert "Apply suggestion from @johha"

8f6369f

This reverts commit 728f705.

Update Ruby to 3.2.9 in gemfile

c8325f2

sethboyles dismissed stale reviews from Samze and johha via c8325f2 December 12, 2025 21:02

sethboyles force-pushed the enforce_ruby_and_bundler_versions branch from 385ba16 to c8325f2 Compare December 12, 2025 21:02

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enforce ruby and bundler versions#4545

Enforce ruby and bundler versions#4545
sethboyles wants to merge 4 commits intomainfrom
enforce_ruby_and_bundler_versions

sethboyles commented Sep 3, 2025

Uh oh!

Uh oh!

johha commented Sep 11, 2025

Uh oh!

philippthun commented Dec 2, 2025

Uh oh!

sethboyles commented Dec 12, 2025

Uh oh!

sethboyles commented Feb 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

sethboyles commented Sep 3, 2025

The Problem

Uh oh!

Uh oh!

johha commented Sep 11, 2025

Uh oh!

philippthun commented Dec 2, 2025

Uh oh!

sethboyles commented Dec 12, 2025

Uh oh!

sethboyles commented Feb 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants